Subject: Propagation of COS tables

From: [email-masked] (Dave Finnie)
Date: Fri, 23 Jun 95 10:11:25 EST

Following on from past discussions on HPR route preference
and the more recent COS table issue being discussed on the
ATM exploder, it seems to me that what is needed is a pair
of architected TPs: The send COS and receive COS TPs.

The above two issues appear to beg for an ability to expand
and alter (and add) COS tables "on the fly", by the customer
issuing a NOF command at a single node in the network, with
that aim that this is propagated throughout the network.

While the APPN architecture stresses that customers avoid
adding COS tables, many do (perhaps because the standard
ones don't address their needs). They are then forced to
define the new COS tables at every NN that will serve OLUs.
Perhaps this is the reason they are discouraged :-)

Jim Cobban recently raised a problem that appears to require
an additional column, and possibly additional rows, in COS
throughout the network. Not only does this mean heavy
configuration on the user part, but also code changes for
every NN. I can imagine most people don't like the idea of
that.

Is there a way that we can remove this configuration burden
and also eliminate (or at least reduce) the requirement for
COS-related route selection code changes in the future ? I 
think so.

A pair of TPs could be designed: 

 * The send COS TP builds a description of a COS table, and
   sends it to all attached NNs or client ENs. The description
   includes all characteristics defined by NOF, plus offsets
   of the relevant attributes in the TG and Node characteristics
   control vectors. This later information could allow NNs
   to receive COS attributes that were designed after the NN
   code was written. All it needs to perform route calculation
   is the min/max attribute values, and an indication of where
   to find the relevant characteristics in the CVs in the 
   topology database.

 * The receive COS TP receives a COS definition and stores it.

NNs would need to be responsible for passing this information
along to the next set of NNs.

Dave Bryant's multicast idea would appear to have been ideal 
for this function - but seems to have disappeared.

What does everyone think about this ?

Dave

---

From: Bryan Stephenson <[email-masked]>
Date: Fri, 23 Jun 1995 11:26:43 -0700

Dave Finnie wrote:

> (description of send COS and receive COS architected TPs)
> 

I think propagating the COS tables is the best solution I've seen yet
to the problem which Jim Cobban raised.  The concept is easy to
understand from the users' point of view, and it is extensible by the
user.  I believe that no matter how many classes of service are
provided, many users will still want to add more.  These TP's would
give them an acceptable way to do that for the first time.

Another possible way to propagate the COS tables would be to
automatically send a new "COS update TDU" when a user modifies a COS
table on any node.  Thus, all COS tables are always kept in sync using
the current TDU mechanism with a new "COS update TDU".  From the
user's point of view, this solution wouldn't appear any different than
the TPs solution, because in both solutions, COS tables would
magically turn into network-wide resources, which is really what the
users want.

What are some other solutions for propagating COS tables?

Is there a better solution for these problems than propagating the COS
tables?

Bryan Stephenson